.QUI IDE & SHIMODAIRA ' 2005*1 2f)26B (A) 17:21/1117: 16/8^4103720553 P 4 



$/N: 09/935,675 

NEC-FI OS/USA (1DE.O06) 

' IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
In re Application of: 

Toshiyuki TAMURA 

Serial!*.: 09/»S,675 Group Art Uftfrt: 2645 




Filed: August 24. 2001 Examiner 



; Simon P. Sing 



For; COMMUNICATION SYSTEM AND ALIGNMENT METHOD OF 
TRANSCODER 

Comrausioner for Patents 
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Alexandria, VA 22313-1450 



Sir: 



PKCLARATION TTMPgat TOTI.» .ot p.e>_ai » UJ} 

I, Toshiyuki Tamuia, do hereby state dial: 

J) I am the inventor of the above-identified application. 



2) Tho merited aad *j«mn for th« communication system ami alignment method 
of the tmnscoder of the present invention was known to mo earlier than October 16 2000 
as shown in the NEC Document T-doe H4Jnm(je&itoi)p mm ted**e3GFr 
T5G-CN4 (TrFO workshop of August 28, 2000, in Seattle, Washington. 

This document (Exhibit 1) is available online at; 

b^J'^^lgpp.ot&ftp/ts^uxWCMjtotDOOll^tsgN^ 04 Seattle/Docs/N4- 
00626 ZIP ~ ~ 

This document (Exhibit 1) was also submitted tn me IDS submittal accompanying 
the original filing of the present Application in the USPTO on August 24 2001 The 
•fttaive publication date of the document (fiahib« I) j, AugU5t 2000, which data is 
reflected on the email document (Exhibit 2) for the distribution of this document, and 
which date is earlier than October 16, 2000. 
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Tad distribution email document (Exhibit 2) is available •* 

oT5, 

3) The oomeno of the enclosed document (Ertublt 1) denonaiiwe (he content of 
the present mvention. as de»hbed «, the .peoiaeaoon of ^ ^ iftvBB 

^rh, C h new dainu 20-39 ^bw.L For example, die eooienis of Figure 3 TBfJ^ 
^ 0B " * °* d00anett(Ea * ibh i)cwlw in Figure 5 rfU,o p^ent Auction 
can be found .« (ho wmWuarion of Fi*irei 6 and 7 of the present Application. 

4) T»6 above dearly evidences a completion of the invention in a WTO country 
before the Octobc 16. 2000, publication date of Siemens TdccN4-000868. 

* "• ten »- te 00 i-feimmian and beliefs UdieW » be trur, and Author diet 
then statanentB were mode widi die knowledge that qrfJlftd ftlse Basement* and the like 
so rlT^ p^nfch^le by fi»e or imprisooeient, or bo(h, under Section 1 OOl ofTtelelS 
of the United State, Code and «bot.«d, willfi,} fcUe 3«e««te n,ay jeopardize the 
validity of the application or any patent i HliC d diereoo. 

Further dedaraots soyeth not. 

Dare: 2rj ^ ~7 . 

Toahiyaki Tamur* 
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SRNS relocation during the TrFO connection 
NEC 

Discussion 

Out-of-band transcoder control 



References: N4-000476(Siemens) f N4-000av1 (Siemens) 
Basic working model 

Ideally, there might be two models to treat SRNS relocation during the TrFO connection. The 
bearer negotiation is performed between each ends or the lu UP is terminated once in the MSC 
where SRNS relocation occurs and perform relocation then seek a chance to reform TrFO 
connection. See the Figure 1 and Figure 2 for the working model and the table 1 shows a 
comparison between two ideas. 



| Remote RNC | 



Local MGW~| | Local RNC(OLD) | | Local RNC(NEW) | 



TrFO connection 



MS relocation 



BKigiSglilliiiaiconneption (IF POSSIBLE) 



Fig.1 End to End negotiation 



| Remote RNC | 



TrFO connection 



TrFO Break 
Function 



Local MGW] | Local RNC(QLD) | | Local RNC(NEW) [ 



MS relocation 



^^^i^^^l^^ii^S^^^^^ 0 ^ POSSIBLE) 



FIg.2 TrFO Break once anyway 





End to end negotiation 


TrFO break once anyway 


Procedure 


Relatively simple. 


Relatively complex. 


Clipping 


Since lu UP initialisation is executed 
between remote RNC and local RNC, 
Clipping could become perceptible. 


No additional clipping to the expected 
clipping due to hard hand over. 



Table 1: Comparisons 

Based on the above comparisons, NEC believes that the TrFO break once anyway method has 
much advance than the other. 



SRNS relocation during the TrFO connection (Focusing on the RFCI handling) 

Basically, NEC sees that the N4-000476 that has presented by Siemens in the last TrFO/TFO 
workshop could be an appropriate as the basic concept of the TrFO call connection model. Thus, 
this paper is written based on the N4-000476 and identifies the necessary clarifications related 
to the RFCI handling. 

1.RFCI handling in the CN in the call set-up procedure 

The figure 3 depicts the RFCI recognition in the CN for the call set-up procedure. The Figure 3 is 
divided into three parts. The understanding of this picture might help to consider the RFCI 
handling for the SRNS relocation. 



| Local RNC | 



I Local MRF~] | Local MGW | 



| Remote RNC | 




TBC recognizes that map-B is for Down link to R-RNC and 
map-A is for Down link to L-RNC. 



Fig. 3-1 Initialization in both side (Step 1) 



I Local RNC | 



1 Local MRF~1 | Local MGW 



TBC 
inserted 



Initialize (RFCI 
map-B) 



Initialize Ack. 




Remote RNC 



RBT applied 



RFCI is known in TBC by 
the sequence in Step 1. 
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Fig. 3-2 Connect to RBT (Step 2) 



| Local RNC | 



Connect 



| Local MR F~~| | Local MGW | 



Subtract (RBT) 



Initialize (RFCI map-B) 



Initialize Ack. 



TBC 
inserted 



| Remote RNC | 



Initialize (RFCI map-A) 



Initialize Ack. 



Each RFCI maps are extended to opposite RNCs. If two acks are received 
successfully, TBC is taken out and establish end to end TrFO connection 



r TrFO connction established 



Flg.3-3 TrFO connection (Step 3) 



In figure 3-3, it might be a problem in case that the initialise NACK is received instead of ACK in 
the local MGW. Since the called MS has answered in this particular phase of a call, it is not 
allowed to disconnect a call. The figure 3-4 illustrates the treatment for this situation. The local 
MGW could use RFCI information obtained by the same direction of the RNC to be initialised. In 
release 99, the reason why there is no initialisation procedure initiated by the core network is 
that the core network always uses the same RFCI set that is informed from the RNC. This idea 
can be utilised in this case. As the result, a call cannot be a TrFO connection. However, it can 
get rid of the worst scenario that is a call disconnection. 
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| Local RNC" 



| Local MR F~| | Local MGW | 



Connect 



Subtract (RBT) 



Initialize (RFCI map-B) 



Initialize Nack. 



Initialize (RFCI map-A) 



Initialize ack. 



| Remote RNC | 



TBC 
inserted 



TrFO connection established 



Initialize (RFCI map-A) 



Initialize Nack. 



Initialize (RFCI map-B) 



Initialize Ack. 



TBC 
inserted 



lu UP established as usual 
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Fig. 3-4 TrFO connection (Step 3-1) 



2.RFCI handling in the CN in the SRNS relocation 

This section considers the RFCI handling for the SRNS relocation based on the description in 
the previous section. The figure 4 illustrates the successfully SRNS relocation. The RFCI to be 
used for both Up link direction and Down link direction are exact same as the one used for the 
old RNC by chance. 



| RNC(OLD) | I RNC(NEW)~| | Local MGW~ 



| Remote RNC 



TrFO connection established 



MS relocation 



RFCI Interrogator 



TBC 
inserted 



Ack. (Map-A for R-RNC map-B for L-RNC) 



Initialize (RFCI map-A) 



Initialize Ack. 



Initialize (RFCI map-B) 



Initialize Ack. 



TrFO connection established 



Fig.4 Successful SRNC relocation 



In the next, The Figure 5 illustrates the case that the supported RFCI in the new RNC does not 
match as the one supported in the old RNC. This condition was made by the following actions: 

• At first, TrFO connection was created by 1) Old local RNC requested to initialise with RFCI 
map-A and succeeded. 2) The remote RNC requested to initialise with RFCI map-B and 
succeeded. 

• The SRNS relocation occurred. Then new local RNC requested to initialise with RFCI 
map-C and succeeded. 

• The TBC requested to initialise new local RNC with RFCI map-C and succeeded. 



| Local RNC~ 



Data (RFC! map-C) 



Data (RFC I ma p-C) 



Local MGW 



TBC 



Data format 
conversion 



| Remote RNC 1 



Data (RFCI map-A) 



Data (RFCI map-B) 



Fig. 5 TBC function 



In order to re-configure the TrFO connection, The CN(TBC) may try the following re-initialisation 
procedure. (RFCI alignment challenge) 

The figure 6 illustrates the RFCI alignment challenge procedure. In the figure, the initialise 
procedure for the remote RNC is only successful so that the TBC only converts user data for the 
direction of remote RNC as the result. 



| Local RNC | 



| Local MGW | 



Remote RNC 



Data (RFCI map-C) 



• . ; Data (RFCI map-C) 



Initialize (RFCI map-B) 



Initialize Nack. 



Data (RFC! map-C 



Data (RFCI map-C) 



<8> 



Data format 
conversion 




Data (RFCI map-A) 



Data (RFCI map-B) 



Initialize (RFCI map-C) 



Initialize Ack. 



Data (RFCI map-C) 



Data (RFCI map-B) 



Fig. 6 RFCI alignment challenge 
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See you in Seattle. 
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